NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/hardware-part1/2923

Internet Message Format | 1996-08-05 | 7.2 KB

Path: sdd.hp.com!inn
From: Jeff Grimmett <[e-mail]>
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A3000 SCSI
Date: 29 Jan 1996 19:28:00 GMT
Organization: Hewlett-Packard Company
Message-ID: <4ej740$[e-mail]>
References: <4crkgh$[e-mail]> <4djffa$[e-mail]> <4dlre0$[e-mail]> <4e0amr$[e-mail]> <4e0jru$[e-mail]> <4edjsc$[e-mail]> <4egdq5$[e-mail]> <[e-mail]>
NNTP-Posting-Host: hpsdv330.sdd.hp.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)

[e-mail] (Dave Haynie) wrote:

>>>No, C= chose to do a couple of things wrong, and the users are the ones
>>>who had to put up with it.  As usual.  To be fair, there may not have
>>>been any conscious choice involved; things like the DB25 connector may
>>>just have been "the way you do it" at that time.

>The DB25 connector was the industry standard for small connectors,
>although not part of the SCSI specs. SCSI at the time (this was
>SCSI-1, after all) called for the Centronics-style 50 pin connector,
>which was too large for a computer like the A3000.

It does appear on some desktop systems even now -- I have one on my desk
-- but they do eat up a lot of real estate.

>This was one big reason that, when I had a SCSI board to designed, I
>dumped Western Digital like yesterday's bad news. Well, that and the
>fact that the NCR 53C7xx chips had become the hot SCSI chip on
>workstations, and I always figured Amigas should aim for the same
>level of performance when possible.

:-)  Can't argue with that logic.


>>THAT is the reality we have to deal with.  The 3000 does NOT comply 100%
>>with SCSI specs.  It comes close.  DAMNED close.  It is, for my money,
>>one of the most compliant controllers for the Amiga market, with the 2091
>>edging it out.
>
>How? The A2091 is in all ways the 16-bit version of the A3000

I have to admit to a purely subjective reason for this.  I simply have
had fewer problems with the 2091 than with the 3000 SCSI system, and have
found under a few circumstances that ONLY a 2091 could be used to revive
a drive that had been fragged by some other controller (such as GVP).
That is the ONLY basis I had for that statement.  And I did use the word
"edged" deliberately -- to indicate that it was a close call for me to
make.

Given that the 2091 was seen to work in situations where the 3000
controller would not, and all other things being equal, I therefore
inferred better compliancy on the part of the 2091.

>>Sure, 50-pins connectors are better from MANY viewpoints, but the things
>>are EXPENSIVE compared to even top quality DB25 to 50-pin cables.

>As I said, everyone used the Apple standard, even it wasn't in the
>SCSI spec. So these cables are made in large quantities, and they're
>cheap. The first place I saw the 50 pin SCSI-2 cable was on a Sun
>Sparcstation. Even price Sparcstation add-ons?

<<shudder>>  The last external drive that I attached to my 3000 was
housed in a Sun HD box.  Sure, it's a NICE box, but when the owner told
me how much he paid for it, I almost had an accident.  I'm in the wrong
line of work -- I should go out and make Sun workstation hard drive
boxes. ;-)

>>Ever price one of the high-density 50 pin cables?  I can get a DB25 type for
>>$15, very good quality build.  The same company also sells a high-density
>>cable.  For SIXTY fraggin' dollars.

>I bought my last one for about $20, it works fine. But that was last
>year; in the early 90s, these would have run you big bucks.

I bought mine last month.  I may not have said it directly, but both the
25 pin and high-density cables were high-end, as is required in my
operating environment.  The price did not suprise me.  The price
DIFFERENTIAL did.

>>>Huh?  In what way is the A3000 SCSI non-standard, other than a minor flaw
>>>in the way it is documented?  Please be specific.
>
>>Well, since you won't accept the notion that at least early A3000
>>motherboards had a problem with SCSI bus impendence, and thus requiring
>>non-standard termination configurations, I sense a trap.

>Don't know what you're talking abou there. There was never a problem
>with SCSI bus impedence, unless this is something in the WD chip,

I was taking a wild guess as to the _reason_ for this bulletin, a
slightly educated guess, but quite possibly wrong.

As I told Warren, I need to dig that sucker out and wave it around a bit.
Oh, for some good OCR software....

>which we never had control over. The termination issues for the
>motherboard were as I described, nothing more, nothing less.

Well, I certainly don't understand the different reports of varying
termination configurations in this light, then.  My system, and all the
ones that I've cracked open, have had socketed terminators on the MB.
Many people are reporting empty sockets, and at least one poor
unfortunate person has reported having HIS soldered to the main PCA.

Is there any possibility that some of these could be explained by
decisions, or non-decisions, made on the manufacturing line?

>>While it claims SCSI-II command
>>compliance, you can not enable and disable synchronous transfers on a
>>drive by drive basis.  You can only enable and disable synchronous
>>transfers globally, for all drives or none of them.  This was openly
>>acknowledge in both technical bulletin AND in developer documentation.

>The issue of synchronous NEGOTIATION is global; you can specific if
>the A3000 will negotiate for synchronous transfers, or not, and that's
>global.

Problem is, if a drive does not support negotiation for synch transfer
(which is likely not to if it does not support the transfer mode at all),
is may cause the whole bus to lock up.  I gather that this is not a
problem for all controllers out there (outside of the Amiga realm).

> I don't know what the SCSI-2 spec said back when the A3000 was
>in progress, or what it said when finalized, on this issue. I do know
>that many SCSI-2 host adaptors on the market, from many vendors, do
>not offer individual controls over whether synchronous mode is
>negotiated or not.

That is to be expected.  As with modems, there are a lot of claims to
compliancy with this or that standard, but often those promises fall
short of reality.  I bet that maybe 1 out of 10 is fully compliant.

>>OK, throw a WD chip, some SCSI driver chips, some resistors, and whatever
>>else you think would be appropriate into a cardboard box, close the lid,
>>and shake vigorously.  Have you now ended up with a standard SCSI
>>controller?  Let me know if this works, I always wanted to get rich.

>While not quite that simple, the point is a valid one -- the SCSI chip
>you use is primarily responsible for delivering a compliant SCSI
>bus. The system designer has little control over the nature of the bus
>itself -- termination, T.P., connector styles, and maybe additional
>buffering (for differential SCSI) are about your only options.

From what I've seen, it seems that the core chip is primarilly
responsible for keeping the SCSI protocols compliant.  You surround it
with the appropriate hardware.  What hardware, how it affects the bus, is
beyond the chip's control.